Skip to content

Update LFRic2LFric to store unique names for it's source and destination meshes - #729

Open
Ricky Wong (mo-rickywong) wants to merge 10 commits into
MetOffice:mainfrom
mo-rickywong:Apps_lfric2lfric_in_and_out
Open

Update LFRic2LFric to store unique names for it's source and destination meshes#729
Ricky Wong (mo-rickywong) wants to merge 10 commits into
MetOffice:mainfrom
mo-rickywong:Apps_lfric2lfric_in_and_out

Conversation

@mo-rickywong

@mo-rickywong Ricky Wong (mo-rickywong) commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

PR Summary

Sci/Tech Reviewer: cjohnson-pi
Code Reviewer: Matthew Hambley (@MatthewHambley)
Updates LFRic2Lfric code to use core changes in MetOffice/lfric_core#452 . These changes, along with those in the linked PR should allow LFRic2Lfric to use generated meshes for re-gridding, even if the meshes where identically named in the seprate mesh input files.

Linked PRs

Code Quality Checklist

  • I have performed a self-review of my own code
  • My code follows the project's style guidelines
  • Comments have been included that aid understanding and enhance the readability of the code
  • My changes generate no new warnings
  • All automated checks in the CI pipeline have completed successfully

Testing

  • I have tested this change locally, using the LFRic Apps rose-stem suite
  • If any tests fail (rose-stem or CI) the reason is understood and acceptable (e.g. kgo changes)
  • I have added tests to cover new functionality as appropriate (e.g. system tests, unit tests, etc.)
  • Any new tests have been assigned an appropriate amount of compute resource and have been allocated to an appropriate testing group (i.e. the developer tests are for jobs which use a small amount of compute resource and complete in a matter of minutes)

Canned test in lfric2fric shows that the source and destination meshes are prepended with src and dst by lfric2lfric. This will satisfy the requirement for unique mesh name in the mesh collections, even if the input files have meshes named the same.

image

Note:
A suitable test case for lfric2lfric to use where meshes of the same name are used in source and destination mesh files. The canned lfric2lfric test was modified so that it would attempt to read the same mesh for source and destination. i.e.

&lfric2lfric
source_meshfile_prefix     = 'mesh_C24_MG',
source_mesh_name           = 'dynamics',
destination_meshfile_prefix = 'mesh_C24_MG_copy',
destination_mesh_name      = 'dynamics',
/

This failed in XIOS during the context creation of the output file. This test is out of scope, but may point to further work on lfric2lfric wrt XIOS output.

trac.log

Test Suite Results - lfric_apps - Apps_lfric2lfric_in_and_out/run1

Suite Information

Item Value
Suite Name Apps_lfric2lfric_in_and_out/run1
Suite User ricky.wong
Workflow Start 2026-08-26T13:31:08
Groups Run developer
Dependency Reference Main Like
casim MetOffice/casim@2026.07.1 True
jules MetOffice/jules@2026.07.1 True
lfric_apps mo-rickywong/lfric_apps@Apps_lfric2lfric_in_and_out False
lfric_core mo-rickywong/lfric_core@lfric2lfric_in_and_out True
moci MetOffice/moci@2026.07.1 True
SimSys_Scripts MetOffice/SimSys_Scripts@77a5166 True
socrates MetOffice/socrates@2026.07.1 True
socrates-spectral MetOffice/socrates-spectral@2026.07.1 True
ukca MetOffice/ukca@9fc2b6d True

Task Information

✅ succeeded tasks - 1218

Security Considerations

  • I have reviewed my changes for potential security issues
  • Sensitive data is properly handled (if applicable)
  • Authentication and authorisation are properly implemented (if applicable)

Performance Impact

  • Performance of the code has been considered and, if applicable, suitable performance measurements have been conducted

AI Assistance and Attribution

  • Some of the content of this change has been produced with the assistance of Generative AI tool name (e.g., Met Office Github Copilot Enterprise, Github Copilot Personal, ChatGPT GPT-4, etc) and I have followed the Simulation Systems AI policy (including attribution labels)

Documentation

  • Where appropriate I have updated documentation related to this change and confirmed that it builds correctly

PSyclone Approval

  • If you have edited any PSyclone-related code (e.g. PSyKAl-lite, Kernel interface, optimisation scripts, LFRic data structure code) then please contact the TCD Team

Sci/Tech Review

  • I understand this area of code and the changes being added
  • The proposed changes correspond to the pull request description
  • Documentation is sufficient (do documentation papers need updating)
  • Sufficient testing has been completed

(Please alert the code reviewer via a tag when you have approved the SR)

Code Review

  • All dependencies have been resolved
  • Related Issues have been properly linked and addressed
  • CLA compliance has been confirmed
  • Code quality standards have been met
  • Tests are adequate and have passed
  • Documentation is complete and accurate
  • Security considerations have been addressed
  • Performance impact is acceptable

@cjohnson-pi

Copy link
Copy Markdown
Contributor

The work to create the possibility of using meshes with the same name in lfric2lfric is very welcome. Thank you.

Some questions to start with:

  1. The fact that XIOS fails during the context creation of the output file is worrying. How confident are you that this can be fixed? i.e. It would be a shame if this work is added and then it turns out that its not possible to create a fix for XIOS. The outcome would be that extra complications have been added to the code unnecessarily. Ideally one would create a proof of concept branch to demonstrate that it will work.
  2. My understanding of the problem is that it is not just the actual lfric2lfric code that cant use meshes of the same name, but also the generate_weights task using ESMF. How confident are you that the generate_weight tasks can be modified to allow for meshes of the same name?

@mo-rickywong

Copy link
Copy Markdown
Contributor Author

The work to create the possibility of using meshes with the same name in lfric2lfric is very welcome. Thank you.

Some questions to start with:

  1. The fact that XIOS fails during the context creation of the output file is worrying. How confident are you that this can be fixed? i.e. It would be a shame if this work is added and then it turns out that its not possible to create a fix for XIOS. The outcome would be that extra complications have been added to the code unnecessarily. Ideally one would create a proof of concept branch to demonstrate that it will work.
  2. My understanding of the problem is that it is not just the actual lfric2lfric code that cant use meshes of the same name, but also the generate_weights task using ESMF. How confident are you that the generate_weight tasks can be modified to allow for meshes of the same name?

As far as the lfric code is concerned, once the meshes are loaded from file, the application can rename them to be stored as what name it likes internally. Everything else downstream of that point would just use the "stored" names that the application has decided on.

I don't work with lfric_XIOS much, though I could well believe that there are names in the xml files which need to match with those being used in the application. That might be all that needs doing? However, there is another question which needs some consideration. Is the name of the mesh referenced in the output from lfric2lfric, if so then some changes may be needed in order to make the output match, i.e. if an application wants a file regridded and all the fields in that file are on a mesh called "dynamics" then the user would probably expect the regridded output to be on a similar name, i.e. "dynamics" rather than "dst_dynamics".

@cjohnson-pi

Copy link
Copy Markdown
Contributor

Thanks for adding the update to the canned test (example). Its great that this demonstrates and tests that the code works using meshes with the same name. (Note - the XIOS problems described above were found to be from using meshes that were inconsistent with the weights file, so this is now fixed).

I believe that the generate_weights_lfric2lfric tasks is entirely separate from the lfric2lfric code (https://github.com/MetOffice/lfric_apps/blob/main/rose-stem/app/generate_weights/bin/generate_weights_lfric2lfric.py is a python script that calls ESMF). Hopefully it will be possible to modify this to allow it to also use meshes of the same name.

I have looked in detail at the code and I cannot find any problems from a science perspective. I'm therefore happy for this to pass science review.

@cjohnson-pi cjohnson-pi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Passes science review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants